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METHOD AND SYSTEM FOR THE OPTIMAL FORMATTING , REDUCTION 
AND COMPRESSION OF DEX/UCS DATA 

CROSS REFERENCE TO RELATED APPLICATION 

This application claims priority from U.S. 
Provisional Patent Application Serial No. 60/203,682, 
filed May 12, 2000, and entitled "METHOD AND SYSTEM FOR 
5 THE OPTIMAL FORMATTING, REDUCTION AND COMPRESSION OF 
DEX/UCS DATA." 

TECHNICAL FIELD 

The present invention relates generally to data 
10 formatting, reduction and compression. More 

particularly, the- present invention relates to a data 
formatting, reduction and compression method and system 
for use in wireless and/or wireline communication 
networks . 
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BACKGROUND OF THE INVENTION 

Over the past decade, vending machine manufacturers 
have developed new and innovative vending equipment in 
response to market needs and vending operator demands. 
5 These innovations have been, for the most part, adopted 
by the beverage vending industry. This trend has been 
influenced by the accelerating rate of technological 
innovation in the electronic and electro-mechanical 
component industry. The availability of new technologies 

10 has given vending machine manufacturers the tools to 

address many of the requirements of vending operators. 
Advances in electronics are now enabling the use of 
computer controls and data acquisition systems directly 
inside the vending machine. Some of the latest vending 

15 machines now make it possible for vending machine 

operators to download sales, inventory, and machine 
health information on-site onto portable computers or to 
transmit the vending machine information to a central 
operations location. 
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SUMMARY OF THE INVENTION 

In accordance with the teachings of the present 
invention, a system and method are provided to allow 
users to extend their corporate enterprise systems into 
5 the field using wireless data technologies. The system 
and method offer information solutions for a wide variety 
of e-commerce services. One aspect of the present 
invention is based on an application services platform or 
network operations center (NOC) upon which users host 

10 their wireless-enabled enterprise applications. The NOC 
manages the complexities of the wireless data realm while 
providing users with seamless access to their field data 
and enabling the integration of hand held wireless 
devices into the system. The present invention may be 

15 efficiently used in vertical industries such as cold 

drink vending, fast food restaurants (fountain drinks) , 
ice merchandising, printing and imaging. Horizontal 
industries which may benefit from the teachings of the 
present invention include refrigeration, field service, 

20 and end-customer enablement using wireless data. 

The present invention is particularly useful as a 
wireless data solution for vending machines that makes 
use of narrowband wireless networks and Internet-based e- 
commerce application services (using Java, XML, WAP, 

25 etc.) to enable vending operators to improve their sales 
and reduce their operational costs. 

Accordingly, a method for efficiently and cost 
effectively communicating data between a network 
operations center and a remote device is provided. The 

30 method may involve transmitting a request for data to at 
least one remote device. Upon receipt of the request for 
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data by the remote device, a current state for the remote 
device is preferably established. After accessing a 
previous state for the remote device, a delta value is 
then preferably calculated between the current state and 
5 the previous state for the remote device. The delta data 
is then written to a device response and the device 
response is sent to the network operations center for 
database updating. In a further embodiment, the delta 
data is compressed before transmission to the network 

10 operations center. 

The present invention also provides a method and 
system for communicating information between a network 
operations center and a remote device. This method of 
communication preferably begins by transmitting at least 

15 one request for information to the remote device. Upon 
receipt of the request, records are selected from a data 
block based upon the request. The selected records are 
then preferably restructured according to a template 
prior to transmitting the restructured records to the 

20 network operations center. In a further embodiment, the 
method may also compress a delta value calculated between 
a current set of restructured records and a previously 
stored set of restructured records. 

In another embodiment, the present invention 

25 provides a method for communicating information between a 
network operations center and a remote device. In this 
"call-in" mode, the method preferably includes selecting 
records from a data block communicatively coupled to the 
device. The selected records are then preferably 

30 restructured according to a template and a delta is 

calculated between the restructured records and a stored 

AUS01:231401.1 



ATTORNEY'S DOCKET 
064814.0132 



PATENT APPLICATION 



5 

set of records. Once the delta has been calculated, the 
delta is preferably transmitted to the network operations 
center. 

In yet another embodiment, the present invention 
5 provides a system for acquiring data at a remote device 
and communicating between a network operations center and 
the remote device. In this preferred "call-in" system, 
the remote device is preferably operable to establish 
communications with the network operations center. The 

10 remote device is preferably further operable to select at 
least one record from a data block communicatively 
coupled to the device. Upon selection of the record, the 
remote device is preferably operable to restructure the 
record according to a template available to the remote 

15 device. Once the record has been restructured, the 

remote device preferably calculates a delta between the 
delta and a stored set of records. The remote device 
then preferably transmits the delta to the network 
operations center via a network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

A more complete and thorough understanding of the 
present embodiments and advantages thereof may be 
acquired by referring to the following description taken 
5 in conjunction with the accompanying drawings, in which 
like reference numbers indicate like features, and 
wherein : 

FIGURE 1 is a block diagram of a system for 
communicating between a remote device and a network 
10 operations center incorporating teachings of the present 
invention; 

FIGURE 2 is a block diagram of one embodiment of a 
remote data acquisition system for vending machines 
according to the present invention; 
15 FIGURES 3A - 3B illustrates a template form for 

restructuring a DEX file according to one embodiment of 
the present invention; 

FIGURES 4-8 illustrate various scenarios of data 
transmission and processing according to one embodiment 
20 of the present invention; 

FIGURES 9A - 9B is a flow chart illustrating one 
example of preferred processing performed by a remote 
device according to one embodiment of the present 
invention; and 

25 FIGURES 10A - 10B is a flow chart illustrating one 

example of preferred processing performed by a network 
operations center according to one embodiment of the 
present invention. 
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DETAILED DESCRIPTION OF THE INVENTION 

Preferred embodiments of the invention and its 
advantages are best understood by referring to FIGURES 1- 
10 of the drawings, like numerals being used for like and 
5 corresponding parts of the various drawings. 

Variable Descriptions, Values and Definitions 
The following variable descriptions, values and 
definitions will be used to describe various features of 
the present invention. 

10 Refill-data - Data stored in the Refill-data portion 

of a getStructuredDexData response. It could be 
State Re fin, delta (A) data between State Re fin and 
State Re fin-oid or other refill related information 
associated with the current state of a device. 

15 Current-data - Data stored in the Current-data 

portion of a getStructuredDexData response. It could be 
State Cu rrent, or delta (A) data between State Cu rrent and 
State Re fiii-oid or other information related to the current 
state of a device. 

20 State Ref iii- dat abase - The refill state that is stored in 

the Network Operations Center (NOC) database. For a new 
device entry in the database, this value is preferably 
null (0) . In the case where the NOC database has the 
latest refill state, State Re fiii- d atabase = State Ref iii. In the 

25 case where the NOC database does not have the latest 
refill state, State Re fiii-database = State Refill _ 0 i d . 

State Ref iii - The most current refill state stored on 
the remote data acquisition and transmission device 
(RDATD) . If the Controller on the RDATD has only been 

30 reset once, State Reflll = State Refin - old . 
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StateRefin-oid - The refill state previous to the 
current refill state, i.e., State Re fin, stored on the 
RDATD. If the Controller has only been reset once 
State Re fiii = State Re fiii-oi.d. State Refi n-oid is also used as a 
5 reference state variable for a remote device. 

State Cu rrent - The complete current state of a RDATD 
controller . 

DataLengthcurrent ~ Length of the Current-data block in 
a getStructuredDexData response: 
10 If DataLengthcurrent = 0, there is no data for 

the current state. 

If DataLengthcurrent = FFFF, there is no change in 
current state since last retrieved. 

If DataLengthcurrent = xxx, the information 
15 contained in the Current-data block of the 

getStructuredDexData response is the actual length 
of the Current-data block. 
DataLength Refill - Length of the Refill-data block in 
a getStructuredDexData response. 
2 0 If DataLength R efin = 0, there is no data for the 

current state. 

If DataLength R efin = FFFF, there is no change in 
Refill-data since last retrieved. 

If DataLength R efiu = xxx, the information 
25 contained in the Refill-data portion of the 

getStructuredDexData response is the actual length 
of the Refill-data block. 

CRC Re fin-database - Cyclic Redundancy Check Value (CRC) 
for the Refill-data that was last received by the NOC and 
30 that is stored in the NOC database. For a new device, a 
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value of zero (0) is preferably stored in the database 
for this field. 

CRC Ref in - the CRC for State Ref ixi, cached on the 
RDATD. 

5 CRCRefin-oid - the CRC for State Re fiii-oid/ cached on the 

RDATD. 

A Re fiii = State Ref in - State Re fin_ 0 i d . 

Acurrent = State Cu rrent " State Re fill. 

The term "wire-line transmissions" is used to refer 

10 to all types of electromagnetic communications over 

wires, cables, or other types of conduits. Examples of 
such conduits include, but are not limited to, metal 
wires and cables made of copper or aluminum, fiber-optic 
lines, and cables constructed of other metals or 

15 composite materials satisfactory for carrying 

electromagnetic signals. Wire-line transmissions may be 
conducted in accordance with teachings of the present 
invention over electrical power lines, electrical power 
distribution systems, building electrical wiring, 

20 conventional telephone lines, ethernet cabling (lObaseT, 
lOObaseT, etc.), coaxial cables, etc. 

The term "wireless transmissions" is used to refer 
to all types of electromagnetic communications which do 
not require a wire, cable, or other types of conduits. 

25 Examples of wireless transmissions for use in local area 
networks (LAN) include, but are not limited to, radio 
frequencies, such as the 900 MHz and 2.4 GHz bands, 
infra-red, and laser. Examples of wireless transmissions 
for use in wide area networks (WAN) include, but are not 

30 limited to, radio frequencies, such as the 800MHz, 
900MHz, and 1.9GHz ranges, infra-red, and laser. 
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FIGURE 1 is a block diagram of a system for 
communicating between a remote device and a network 
operations center incorporating teachings of the present 
invention. System 100 of FIGURE 1 preferably includes 
5 network operations center 126 communicatively coupled to 
wide area network (WAN) device 130 and local area network 
(LAN) device 134 via wide area network 124. Wide area 
network 124 can be either a wireless or a wire-line 
network. 

10 System 100 can preferably utilize at least two 

different communication schemes for communicating between 
the network operations center 126 and WAN device 130 
and/or LAN device 134. One communication scheme is the 
DEX/UCS protocol of data transfer as indicated at 138. 

15 The second communication scheme is a delta scheme for 

transmitting data from LAN device 134 and WAN device 130 
to NOC 126 and vice versa as indicated at 142. The delta 
scheme of communication reduces the amount of data 
necessary to provide complete updated information to NOC 

20 126 and database 230. 

The delta scheme of the present invention utilizes a 
getStructuredDexData command to achieve this reduction in 
transmitted information. The getStructuredDexData 
command preferably selects records specified in a 

25 template from an original DEX/UCS data block associated 
with a remote device, restructures the records in a 
preferred order, and calculates a delta (A) or difference 
between a previous state and the current state of the 
remote device. Instead of sending the entire 

30 restructured data block, only the delta (A) is 

transmitted to NOC 12 6. In one embodiment, the delta is 
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compressed, using a conventional compression algorithm 
such as zip, gzip, etc., before transmitting the delta to 
the NOC 126. NOC 126 can recreate the current state of 
the remote device from delta (A) and values for a 
5 previous state that are stored in a database. The 

information associated with the various states of the 
remote device can include inventory levels, number of 
vends, condition of device hardware, as well as any other 
characteristic capable of being monitored and contained 

10 in the original DEX/UCS data block. 

FIGURE 2 is a functional block diagram of one 
embodiment of a remote data acquisition system for 
vending machines, indicated generally at 210, according 
to the present invention. In general, system 210 of 

15 FIGURE 2 communicates information from a vending site 212 
externally over a wide area wireless or wire-line network 
and internally over a local area wireless or wire-line 
network. As shown, the local area network at vending 
site 212 can be referred to as a device interrogation LAN 

20 subsystem (DIL) . Vending site 212 may include only one 
vending machine 214 or a plurality of vending machines 
214. Each vending machine 214 may include vending 
hardware (not expressly illustrated) and inventory 216 
for performing vending functions and electronically 

25 tracking some vending information. Vending machines 214 
may provide various types of products to customers such 
as soft drinks, snacks, etc. 

According to the present invention, each vending 
machine 214 may include an application controller 218 

30 coupled to and interfacing with vending hardware and 

inventory 216. Many vending machines 214 are equipped 
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with electronics for controlling vending operations as 
well as tracking some vending events such as money 
received, change given and number of vends from each 
slot. Application controllers 218 can communicate with 
5 such embedded electronics as well as be equipped to 

directly sense other vending events and vending equipment 
parameters (e.g. compressor performance). Application 
controllers 218 can also communicate with one another and 
the application host 222 via onboard transceivers using 

10 wire-line or wireless transmissions. According to the 

present invention, either the application controller 218 
or the application host 222 can be configured to process 
the getStructuredDexData request or command, to 
restructure a DEX/UCS data block or to calculate delta 

15 (A) values. 

Together, application controllers 218 and 
application host 222 form a LAN supported by the wire- 
line and/or wireless transmissions 220. In addition, 
application controllers 218 can also act as repeaters in 

20 case application host 222 cannot directly communicate 
with a particular application controller 218 while 
another application controller 218, which does have an 
established communication link with application host 222, 
can directly communicate. 

25 Application host 222 acquires data captured by 

application controllers 218 and, preferably using the 
delta scheme of the present invention, can package and 
communicate that data across an external network 124 
using a wide area network (WAN) interface. Application 

30 host 222 can be installed together with application 
controller 218 inside a vending machine or housed 
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separately in another location. In the event that the 
application host 222 is placed inside a vending machine 
together with an application controller 218, it is 
possible to share some of the electronic components 
5 between them, the LAN transceiver for example, in order 
to reduce the cost of the hardware. In this case, the 
application host 222 and application controller 218 
inside the same vending machine, would preferably 
communicate with each other over a hardwired interface 

10 between the two components. Alternatively, the 

application host 222 and application controller 218 can 
be designed to be a single integrated component within a 
vending machine. Furthermore, an application host 222 
can be used whose function preferably consists of 

15 monitoring the application controllers 218. For example, 
such an application host 222 could take the form of a 
hand-held portable computer 223 to be carried by service 
or delivery personnel in order to query the application 
controllers 218 without having to interact via the WAN 

20 interface 229. In one embodiment, application host 222 
and/or application controller 218 may be used to perform 
the preferred functions associated with the automated or 
"Call-In" mode of operation mentioned above. 

The WAN interface 22 9 can be implemented in a number 

25 of ways. In particular, WAN interface 229 is designed to 
support a wide area network 12 4 that can be implemented 
via wire-line or wireless transmissions. If a wireless 
. narrowband PCS paging network is used to implement the 
WAN, messages from application host 222 can be 

30 communicated as digital messages through the paging 
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network, stored and delivered by the network carrier to 
the NOC using, for example, a secure Internet connection. 

As shown in FIGURE 2, a network operations center 
(NOC) 126 communicates with one or more vending sites 212 
5 across wide area network 124 using the delta scheme of 
the present invention. As mentioned, in one 
implementation, network operations center 126 can access 
information transmitted by application hosts 222 at 
vending sites 212 using the network carrier's 

10 infrastructure. In the embodiment of FIGURE 2, network 
operations center 126 includes a NOC control 228 that 
communicates with wide area network 124 through a WAN 
interface 22 9. NOC control 228 can receive data acquired 
from and transmit data to vending sites 212, process the 

15 data and store the data into database 230. NOC control 
228 can also perform instant alert paging, direct dial 
alarms and other functions to provide real time 
notification to a vending operator upon the occurrence of 
certain events (e.g., out-of -stock, power outage, 

20 vandalism, etc.). NOC control 228 can also provide third 
party transaction processing such as allowing queries on 
database 230. The WAN interface 229 between NOC control 
228 and the wide area network 124 can be implemented 
through the use of either wire-line or wireless 

25 transmissions. 

At network operations center 126, a client access 
point 232 provides access from a client interface 
subsystem (CI) 234 across external network 224. In one 
implementation, client access point 232 can be a web- 

30 based interface allowing user access from a client 

computer across a network such as the Internet. Other 
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implementations include providing a direct-dial 
connection between client interface subsystem 234 and 
client access point 232. Once connected, a user can use 
client interface subsystem 234 to obtain information from 
5 database 230 based upon data acquired from vending sites 
212. Further, users can be provided with extended 
services such as trend information developed by mining 
and analyzing database 230. 

According to the present invention, system 210 of 

10 FIGURE 2 combines a number of technologies to provide 
technical advantages in the area of vending machine 
management, to reduce various operational costs and to 
overcome existing network traffic problems with 
conventional remote data acquisition systems for vending 

15 machines. As mentioned above, some conventional remote 

data acquisition systems employ a point-to-point wireless 
communication link to retrieve information from and send 
information to a plurality of remote devices. Further, 
wide-area networks (WAN) are often formed from a 

20 plurality of local area networks (LANs) , and such LANs 
are often interconnected using a wire-line or wireless 
data transmission system. In other technical areas, 
wire-line and wireless transceivers have been used for 
local area network communication. 

25 Delta scheme 142 of the present invention enables 

network data volume and communication time between NOC 
126 and remote devices 130 and 134 to be minimized. 
Delta scheme 142 functions to minimize the amount of 
information necessary to be communicated between NOC 12 6 

30 and devices 130 and 134 such that the complete state 
information of each device is maintained at NOC 12 6. 
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FIGURES 3A-3B illustrate one embodiment of the 
fields of a DEX/UCS block which has been restructured in 
response to a getStructuredDexData request. As 
illustrated in FIGURES 3A-3B, the DEX/UCS data block is 
5 preferably sectioned off into four categories. Category 
305 preferably includes special fields, category 310 
preferably includes fields that do not change frequently 
while category 315 preferably contains the fields that 
are likely to change frequently. Category 320 preferably 

10 includes the non-standard fields of a DEX/UCS data block. 
Restructuring the DEX/UCS data block allows for very high 
compression ratios to be achieved after the delta is 
calculated. These compression ratios may not be 
achievable without the restructuring of the DEX/UCS data 

15 block. 

Software (not expressly shown) incorporating 
teachings of the present invention running on a device 
end, such as software running on application controller 
218 or application host 222, will restructure the DEX/UCS 

20 data block according to a template framework, such as 
that illustrated in FIGURES 3A-3B, and by following a 
preferred set of rules. The preferred set of rules 
includes: to calculate Ai 0 , state 0 is subtracted from 
statei,. if the DEX/UCS data block obtained from the RDATD 

25 controller does not contain a particular record type 

expected in the template, a character, such as a carriage 
return character (<CR>) , is written to the restructured 
data block; if the data block from the RDATD controller 
contains a particular record type that is not expected in 

30 the template, it is ignored; for each record, only the 
fields of interest are considered (For example, for the 
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record "PA2*9888*543660*9882*543510" we may only need to 
send information "9888" and "543660,-" making our desired 
record "PA2*9888*543660 . " ) ; for records that match, a 
<CR> is written to the restructured block; for records 
that don't match, the record identifier is skipped and a 
delta is calculated only for the remaining portion, (For 
example, for the two records "MA5*SEL1*1, 7*9821, 10086" 
and "MA5*SEL1*1, 7*5696*5845, " the delta is calculated for 
"1,7*9821*10086" and "1,7*5696*5845" portions only.); the 
delta is calculated on a per field basis, i.e., the 
fields separated by "*'s"; if a required field is absent 
in the DEX data block received from the RDATD controller, 
the restructured data block will have two contiguous 
"*'s" for that field; if all the bytes in the delta for a 
field are binary 0's (zeroes), the delta is considered to 
be empty and there is no delta data for that field to be 
written, (In this situation, there will be only two "*'s" 
in the record with no field value in between.); each such 
delta, except for the last record in line, is written to 
the restructured block followed by a "*"; the last record 
written to the restructured data block is followed by a 
<CR>; for fields that are not of equal length, e.g., 
"5845" and "10086," the shorter field is padded at the 
end with the appropriate number of 0's (zeroes) to make 
it equal in length to the longer field, (A delta is 
preferably calculated on two equal length fields.); 
since blank characters are allowed in the DEX/UCS data 
block, binary zeroes (0's) will be used for padding a 
shorter field to make it equal in length to the longer 
field, (This helps in reconstructing statei from state 0 
and delta.); instead of "1 * 55", it is desirable to 
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minimize the size of the restructured data block and use 
"1*55" instead; by using 0 (zero) when adding the state 0 
byte and the delta byte equals 0 (zero) we discard that 
byte since it was used for padding; and non-standard 
5 records are written to the very end of the restructured 
data block without calculating a delta. 

FIGURES 4-8 illustrate one example of preferred 
steps processed by NOC 12 6 and device 4 00, such as a 
remote vending unit 214, during various 

10 getStructuredDexData requests. In FIGURES 4-8, the DEX 
data block is restructured at the remote device upon 
receipt of the getStructuredDexData request. 
Restructuring the DEX/UCS data block can also occur at 
other times during the processing of the 

15 getStructuredDexData request. In addition to calculating 
a delta in response to receipt of a getStructuredDexData 
request, a remote device may be configured to operate in 
an automated mode. This automated or "Call-In" mode is 
preferably configured such that a delta is calculated, 

20 generally as defined below, in response to a 

predetermined event, such as at a certain time, a 
threshold number of transactions, etc., and then 
transmitted to NOC 126. 

FIGURE 4 illustrates the processing and 

25 transmissions which occur when NOC 126 transmits a 
getStructuredDexData request for State C urrent or the 
complete current state of device 400. As illustrated in 
FIGURE 4, NOC 12 6 transmits a getStructuredDexData 
request to get an update of the State Cu rrent of device 400. 

30 Included in the getStructuredDexData request for a 

Statecurrent update, is the check value CRC Re fiii- D atabase as 

AUS01: 231401.1 



ATTORNEY'S DOCKET 
064814.0132 



PATENT APPLICATION 



19 

indicated at 405. In response to receipt of the 
getStructuredDexData request for a State Cu rrent update, 
device 400 preferably writes CRC Cu rrent and State Curren t to a 
device response and then transmits the device response to 
5 NOC 126 as indicated at 410. In one embodiment, the 

information written to the device response is compressed 
prior to being written. Upon receipt of the device 
response containing CRC Cu rrent and State Cu rrent/ NOC 12 6 
preferably recreates a current state from values stored 

10 in database 230 and the values of CRC Cu rrent and State Cu rrent 
provided in the device response. 

FIGURES 5A-5C illustrate the processing which can 
occur in response to a getStructuredDexData request for 
the Acurrent of device 400. FIGURE 5A illustrates one 

15 embodiment of the preferred steps that occur when 
updating database 230 with the changes which have 
occurred at device 400 since database 230 was last 
updated. As indicated at 505, to update database 230 
with the current changes that have occurred at remote 

20 device 400, NOC 126 sends a getStructuredDexData request 
for Acurrent to device 400. Included in the 

getStructuredDexData request for A Cu rrent is error checking 
value CRC Re fin-Database. Upon receipt of the A Cu rrent request 
and the CRC Re fiii-Database value, device 400 performs the steps 

25 indicated at 510. Device 400 begins by comparing the 

value of CRC R efiii-Database provided by NOC 12 6 to a value of 
CRC Re fin accessible by device 400. A comparison of the 
values of CRC Refill - Database and CRC Refill is performed to 
verify that NOC 126 and database 230 have the most 

30 current value for State Re fin of device 400. If the values 
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of CRC Ref in-Database and CRC Re fin are found to be equivalent, 
device 400 can then calculate A Curreri t by subtracting 
State Re fin from State Cu rrent using a previously restructured 
data block or by restructuring a data block before 
5 calculating A Cur rent. Device 400 will also preferably 

calculate a CRC CU rrent value by applying a CRC function to 
State Cu rrent- Once device 400 has completed all of the 
processing steps necessary to provide NOC 126 with the 
information requested, CRC CU rrent and A Curre nt are written to 

10 a device response and transmitted to NOC 12 6 for 

processing as indicated at 515. The current state of 
device 400, the CRC calculated as well as other variables 
are stored by device 400 as previous state information 
for use with the next getStructuredDexData request once 

15 the device response has been transmitted. 

Upon receipt of CRC Cu rrent and A Cu rrent by NOC 12 6, 
database 230 is updated to reflect the current state of 
device 400. As indicated at 520, to update database 230, 
Acurrent is added to the value of State Re fin-Database stored in 

20 database 230 to recreate State Cu rrent or the current state 
of device 4 00. Once State Cu rrent has been stored, database 
230 will then contain the current state of device 400. 
This updated information can be used to issue service 
calls, page a distributor to replenish inventory, or 

25 perform a myriad of other functions. 

FIGURE 5B illustrates the processing which 
preferably occurs when CRC Re fiii-Database is compared to the 
value of CRC Ref iii, during the processing of a 
getStructuredDexData request for A Cu rrent by device 400, 

30 and the two are not equal. As indicated at 525, an 
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attempt by device 4 00 to interpret the value of CRC Refi n- 
Database provided is made by comparing the value of CRC Refi ii- 
Database against the value of CRC Refi ii_oid that is available 
to device 400. If the value of CRC Re fiii-Database matches the 
5 value of CRC Re fiii-oid, this indicates that the value of 
CRCRefiii-Database provided by NOC 12 6 represents an older 
State Re fin at NOC 126 than the latest State Re fin 
transmitted by device 400. In such a situation, device 
4 00 preferably provides A Curren t and A Refi ii to NOC 12 6 in 

10 order to update their corresponding values in database 
230. As indicated at 525, A Re fin is calculated by 
subtracting State Refi n_oid from State Re fin. A Cu rrent is 
calculated as described - above . 

Once Acurrent and A Ref iii have been calculated, a device 

15 response is written, preferably using compressed data, 
and the update information is then transmitted to NOC 
126. As indicated at 530, the information preferred to 
properly update database 230 includes Acurrent, A Refi ii, 

CRC Re fin, CRC Re fin-oid and CRC Cu rrent • Upon receipt Of Acurrentf 

20 A Ref iii, CRC Ref in, CRC Refill _oid and CRC Cu rrent by NOC 12 6, 
database 230 is updated. As indicated at 535, the 
current refill state or State Re fiii of device 400 is 
calculated by adding A Ref iii to State Re fiii- Da taba5e at NOC 12 6. 
The State Ref iii value is then stored as an updated 

25 State Refill _ Da tabase value. The current state or State Cu rrent of 
device 400 is recreated by adding A Current to State Re fin. 
The new State Cur rent value is then stored in database 230. 
Each CRC check value is also preferably stored in 
database 230 to update the check values each represents. 
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If device 400 determines that the value of CRC Re fin- 
Database does not equal the value of CRC Re fin or CRC Re fin-oicu 
device 400 preferably transmits the complete State Re fin 
and A Current based on the current state of device 400. As 
5 illustrated at 540 of FIGURE 5C, A Cu rrent is calculated by 
subtracting State Re fin from State Cu rrent • Once A Cu rrent has 
been calculated, device 400 transmits A CU rrent, State Re fin, 
CRCcurrent and CRC Refi ii in a device response to NOC 12 6, as 
indicated at 545. Upon receipt, NOC 126 recreates and 

10 updates the appropriate variables stored in database 230. 

To obtain the refill state or State Re f±ii from device 
400, NOC 126 may transmit a getStructuredDexData 
indicating such a request. As illustrated at 605 of 
FIGURE 6, a request for a State Re fin update includes the 

15 transmission of CRC Re fiii- D atabase • Similar to the request 
for the State Cu rreiit update of FIGURE 4, device 4 00 
preferably does not compare the value of CRC Refi n- Databa3e to 
any local CRC values. As indicated at 610, device 400 
transmits CRC Ref iii and State Ref in to NOC 12 6 in response to 

20 the request for a State Refil i update. Upon receipt of the 
device response containing the State Ref iii update, NOC 126 
recreates the current state of device 400 based upon 
values stored in database 230 and the values of CRC Refi ii 
and State Ref iii. Database 230 is then updated accordingly. 

25 Illustrated in FIGURES 7A-7C is the processing and 

transmissions which occur when NOC 126 transmits a 
getStructuredDexData request for A Ref iii to device 400. As 
indicated at 705, transmitting a getStructuredDexData 
request for A Refi ii preferably includes transmitting 

30 CRC Re f ill-Database to device 400 from NOC 126. Upon receipt 
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of the getStructuredDexData request for A Re fin, device 400 
uses the CRC Re fiii- D atabase value supplied to verify that NOC 
12 6 has the most current refill state or State Re fin for 
device 400. If the value of CRC Re fiii- D atabase matches the 
5 value of CRC Re fin when compared, as illustrated at 710, 

device 400 can then transmit the information requested by 
NOC 126 in a device response. If the State Refi ii of device 
400 has not changed since the last time device 400 
updated database 230, device 400 transmits a 

10 DataLength Re fin value equal to "FFFF," as indicated at 

715, to NOC 126 to indicate that no change has occurred. 

If device 400 compares the value of CRC Re fin-Database to 
the value of CRC Re fin and determines the values to not be 
equal, as indicated at 720 of FIGURE 7B, device 400 will 

15 then compare the value of CRC Re fiii- D atabase to the value of 
CRC Re fiii-o:Ld • If the value of CRC Re fin-oid matches the value 
of CRC Ref in-Database, indicating that the State Re fin of device 
400 has indeed changed since database 230 was last 
updated, A Re fin is calculated by subtracting State Re fin- 0 id 

20 from State Re fin. A Re fin is then written to a device 

response and transmitted to NOC 12 6. In addition to 
A Re fiii, CRC Re fin and CRC Re fin-oid are also transmitted to NOC 
126 in the device response as indicated at 725. 

Should device 400 determine that the value of 

25 CRC R efin-Database transmitted by NOC 12 6 does not equal the 

value of CRC Refi ii or the value of CRC Re fiii-oid, as indicated 
at 730 of FIGURE 7C, device 400 will then transmit 
State Re fin to NOC 12 6. In addition to State Re fin, device 
4 00 transmits CRC Ref iii and CRC Refi n_oid to NOC 12 6 as 
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indicated at 735 such that database 230 can be updated 
accordingly. 

FIGURE 8 illustrates one method of adding a new 
device to database 230. As illustrated at 805 of FIGURE 
5 8, device 400 transmits unsolicited state information to 
NOC 126, i.e. in an automated or "Call-In" operating 
environment. Information included in an unsolicited 
transmission from a newly added device 400 might include 

CRC Re fill, CRCcurrentr and 

"Current • 

The Acurrent transmitted by 
10 device 400 is calculated by subtracting State Refi ii from 

State Cu rrent- 

Upon receipt of the unsolicited transmission 
indicated at 805, NOC 126 begins processing by comparing 
the value of CRC Refill provided by newly added device 400 

15 with the value of CRC Refil i_ Database in database 230 for 

device 400. Since, in this scenario, device 400 is new 
to the system, the value of CRC Re fiii- D atabase will be empty 
or zero (0) . After determining that device 400 has 
recently been added to the system, NOC 12 6 transmits a 

20 getStructuredDexData request to device 400 as indicated 

at 810. In the getStructuredDexData request sent at 810, 
NOC 12 6 requests both State Refil i and A Cu rrent from device 
400. 

Device 400 responds to the receipt of the 
25 getStructuredDexData request from NOC 126 by transmitting 
the information requested. As indicated at 815, 
information included in a getStructuredDexData request 
for State Re fiii and A Cu rrent preferably includes CRC Refi u, 
CRCcurrent, State Refi ii and A Curren f 
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Once NOC 12 6 receives the information requested, 
database 230 can then be updated as indicated at 820. 
Database 2 30 updates the value of CRC Re fin-Database by 
setting its value equal to the value of CRC Re fiii received. 
5 State Re fin is also stored in database 230. The value of 
State C urrent in database 230 is created by summing A CU rrent 
and State Re fiii- 

An alternative to the method of FIGURE 8 for adding 
a new device to the system involves scheduling NOC 126 to 

10 transmit a getStructuredDexData request for State Refi ii and 
Acurrent immediately after a new device is brought online. 
This proactive approach would eliminate the transmission 
which occurs at 8 05 of FIGURE 8 leaving only the 
processes and transmissions indicated at 810, 815 and 

15 820. 

FIGURES 9A-9B illustrates a flow chart indicating 
the preferred processing performed by device 400 upon 
receipt from NOC 12 6 or upon the automated execution of a 
getStructuredDexData request. Each of the scenarios 

20 encountered by device 400 in FIGURES 4-8 are generally 
processed according to method 900 of FIGURES 9A-9B. 

Persons having ordinary skills in the art can 
appreciate the changes to FIGURES 4-9 which occur in a 
"Call-In" mode of generation. Upon receipt of the 

25 getStructuredDexData request from NOC 126, any 

information, such as return Node ID, CRC Re fiii- D atabase, and 
flag information, included in the getStructuredDexData 
request is extracted, as indicated at step 905. Once the 
information has been extracted, the flag information is 

30 evaluated to determine if the getStructuredDexData 
request includes a request for the Refill-data 
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information of device 400. If it is determined, at step 
910, that the getStructuredDexData request includes a 
request for the Refill-data of device 400, method 900 
proceeds to step 915 to determine if the Refill-data 
5 request is a request for the State Re fiii o r a request for 
the A Re fin of device 400. Alternatively, if at step 910 
it is determined that the getStructuredDexData request 
received from NOC 12 6 does not include a request for the 
Refill-data of device 400, method 900 proceeds to step 

10 917 where a DataLength Re fin value equal to zero (0) is 
written to the device response. In a preferred 
embodiment of the present invention, data is compressed 
before being written to a device response. 

At step 915, if it is determined that the 

15 getStructuredDexData request includes a request for 

A Re fiii, method 900 proceeds to step 920 for a comparison 
of the CRC Re fiii value of device 400 with the value of 
CRC Re fiii-Database provided by NOC 12 6. If the value of 
CRC Re fin is equal to the value of CRC Re fiii- D atabase/- method 

20 900 proceeds to step 925 where a DataLength Ref iu value 
equal to "FFFF" is written in the device response. A 
DataLength Re fiii value equal to "FFFF" indicates to NOC 12 6 
that there has been no change in the Refill-data since 
the last update requested from and transmitted by device 

25 400. Once the device response has been written, method 
900 proceeds to step 930. 

Alternatively, if at step 920 the value of CRC Re fin 
is determined to be different than the value of CRC Re fin- 
Databaser method 900 proceeds to step 935. At step 935, the 

30 value of CRC Re fin-Database is compared to the value of 

CRC Ref in-old- If the value of CRC Re fin-oid equals the value 
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of CRC Ref iii-Database , method 900 proceeds to step 940. At 
step 940, A Refil i is calculated by subtracting State Re fin-oid 
from State Re fiii. A Re fiii is then written into a device 
response. Additionally, CRC Re fiii is written in the device 
5 response to enable the value of CRC Re fin -Database in database 
230 to be updated. Upon completion of step 940, method 
900 proceeds to step 930. 

Should the value of CRC Re fin-oid differ from the value 
of CRC Ref iii-Database , method 900 proceeds from step 935 to 

10 step 945. If the value of CRC Re fin-oid should differ from 
the value of CRC^tm-Database, database 230 at NOC 12 6 will 
require a State Re fin update. At step 945, a State Re fin and 
a CRC Re fiii value are written to a device response. Upon 
receipt of the device response at NOC 126, database 230 

15 can then be updated with the values of CRC Re fin and 

State Re fiii provided. Upon completion of step 945, method 
900 proceeds to step 930. 

At step 930, the flags received in the 
getStructuredDexData request sent by NOC 126 are 

20 evaluated to determine if NOC 126 is requesting Current- 
data information from device 400. If, at step 930, it is 
determined that the getStructuredDexData request does not 
include a request for Current-data, method 900 proceeds 
to step 950 where a value of zero (0) is written in the 

25 device response for Current-data. Once step 950 has been 
completed, method 900 proceeds to step 955 where the 
response written by method 900 is transmitted to NOC 126. 

Should it be determined at step 930 determine that 
the getStructuredDexData request includes a request for 

30 Current-data from device 400, method 900 proceeds to step 
960. At step 960, it is determined whether the 
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getStructuredDexData request includes a request for a 
Acurrent update or a request for a State CU rrent update. If a 
Statecurrent update is requested, method 900 proceeds to 
step 965 where State Cu rrent and CRC Cu rrent for device 400 are 
5 written a device response. Once State Cu rrent and CRC Cu rrent 
have been written to the device response at step 965, 
method 900 proceeds to step 955 where the device response 
is transmitted to NOC 126. 

If a request for A CU rrent is included in the 

10 getStructuredDexData requested sent by NOC 126 as 

determined at step 960, method 900 proceeds to step 970. 
CRC Re fin is compared to the value of CRC Re fiii-Database at step 
970. If the value of CRC Refi ii is determined to equal the 
value of CRC R efiii-Database at step 970, method 900 proceeds 

15 to step 975. At step 975, A Cur rent is calculated by 

subtracting State Refil i from State CU rrent and written to a 
device response as is a CRC C urrent value . Once A Cu rrent and 
CRCcurrent have been written to the device response, method 
900 proceeds to step 955 where the device response is 

20 transmitted to NOC 126. 

Should it be determined at step 970 that the value 
of CRC Re fin does not equal the value of CRC Re f ill-Database r 
method 900 proceeds to step 980 where the value of 
CRC Re fin-oid is compared against the value of CRC Re fiii-Database- 

25 If the value of CRC Re fiii-oid is determined to not equal the 
value of CRC Re fin -Database at step 98 0, State Re fxii and CRC Re fin 
are written to a device response at step 985. If the 
value of CRC Re fin-oid is determined to equal the value of 
CRC Re fin-Database at step 98 0, A Re fin is calculated by 

30 subtracting State Re fin-oid from State Refi ii. A Re fin is then 
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written to the device response along with CRC Re fin at step 
990. Upon completion of either step 985 or 990, method 
900 proceeds to step 975 for the processing described 
above and then on to step 955 where the device response 
5 is transmitted to NOC 12 6. Based upon the above 

descrition, a person having ordinary skill in the art can 
appreciate the changes to FIGURE 4-9 which occur when 
device 400 is operated in a "Call-In" mode. 

FIGURES 10A-10B illustrates a flow chart indicating 

10 the preferred processing performed by NOC 126 upon 

receipt of the device response created by device 400 in 
response to a getStructuredDexData request. Each of the 
scenarios encountered by NOC 126 in FIGURES 4-8 are 
preferably performed according to method 1000 of FIGURES 

15 10A-10B. Upon receipt of the device response created by 
method 900, method 1000 preferably begins by extracting, 
such as uncompressing compressed data, the value of 
DataLength Re fin as indicated at step 1005. Once the value 
of DataLength Re fin has been obtained, method 1000 proceeds 

20 to step 1010 where DataLength Refill is compared against a 
null (0) character. If it is determined at step 1010 
that the value of DataLength Re fin is equal to the null (0) 
character, method 1000 proceeds to step 1015 where the 
value of CRC Refill , provided in the device response created 

25 by method 900, is stored in database 230 as the value of 
CRC Ref in-Database • As a result, method 1000 is complete and 
the appropriate values of database 230 have been updated 
as indicated at 1020. 

At step 1010, if it is determined that the value of 

30 DataLength Refi n is something other than the null (0) 

character, method 1000 proceeds to step 1025. At step 
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1025, the value of DataLength Ref iii is compared to the 
value "FFFF". If the Refill-data of device 400 has not 
changed since the last device response transmitted by 
device 400, the value of DataLength Re fin is equal to 
5 " FFFF" and method 1000 will then proceed to step 1020. 

If, at step 1025, it is determined that the value of 
DataLength R efin does not equal "FFFF", method 1000 
proceeds to step 1035. At step 1035, the values of 
StateRgfiii, Date/Time Re fiii, Flag Re fin, CRC Re fiii, CRC Re fiii-oid 

10 and Refill-data are obtained. Once the desired values 
have been obtained, Flag Re fin is tested at step 1040 to 
determine whether the Refill-data included in the device 
response is a State Re fin update or A Re fin information. If 
Flag Re fin indicates the information included in the device 

15 response is for a State Refi ii update, method 1000 proceeds 
to step 1045 where the Refill-data information and the 
value of CRC Re fin are stored in database 230. Once the 
storage is complete, method 1000 proceeds to step 1020 to 
repeat the method of FIGURES 10A-10B using Current-data 

20 vales and variables in place of Refill-data values and 
variables . 

Alternatively, if it is determined at step 1035 that 
the value of Flag Re fin indicates that A Re fin information is 
included in the device response received by NOC 126, 

25 method 1000 proceeds to step 1050. At step 1050, the 

value of CRC Re fiii-oid is compared to the value of CRC Re fin- 
Database- If the value of CRC Re fin-oid does not equal the 
value of CRC Re fin-Databasef method 1000 proceeds to step 1055 
where a getStructuredDexData request for a State Re fin 

30 update and A CU rrent is preferably generated and 
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subsequently transmitted to device 400 before NOC 126 
ends current processing at 1060. 

If it is determined that the value of CRC Re fin-oid 
equals the value of CRC Re fiii-Database at step 1050, method 
5 1000 proceeds to step 1065 where State Re fiii is calculated 
by summing Refill-Data and State Re fin-Database • Also at step 
10 65, CRC Re fiii-caic is calculated by applying an appropriate 
CRC function to the value of State Re fin. Once a value of 
CRC Re fin-caic has been calculated, it is compared to the 

10 value of CRC Re fin at step 1070. The value of CRC Ref in-caic 
is compared to the value of CRC Re fin to determine if the 
information included in the device response received can 
be used to update the information maintained by database 
230. If the value of CRC Re fin-caic does not equal the value 

15 of CRC Re fiii, method 1000 proceeds to step 1055 for the 
processing described above and ends at 1060. If the 
value of CRC Re fin-caic equals the value of CRC Re fin, method 
1000 proceeds first to step 1045 database 230 is updated 
and then on to 1020. Based on the above description, a 

20 person having ordinary skills in the art can appreciate 
the changes to FIGURES 4-10 when device 400 is operating 
in a "Call-in" mode. 

Although the present invention has been described 
with respect to a specific preferred embodiment thereof, 

25 various changes and modifications may be suggested to one 
skilled in the art and it is intended that the present 
invention encompass such changes and modifications fall 
within the scope of the appended claims. 
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